\chapter{Configurazione Avanzata di Reti Virtuali}\label{capitolo:evoluzione_visualnetkit}
\markboth{Configurazione Avanzata di Reti Virtuali}{}

\begin{flushright}
\begin{footnotesize}
Per ``abbracciare il cambiamento'', le strutture, il design, devono seguire le funzionalità di una applicazione in modo continuo. In un mondo in cui il cambiamento è un fattore primario e spesso violento, per seguire le funzionalità, le strutture devono essere continuamente messe in discussione e rimodellate.\\
\end{footnotesize}
\begin{footnotesize}
\textit{Francesco Cirillo}.
\end{footnotesize}
\end{flushright}

Come introdotto nel capitolo \ref{capitolo:arte}, \visualnetkit{} offre un'ottima flessibilità a livello architetturale grazie alla sua struttura modulare che si appoggia su \plugin{}; allo stesso tempo però questa malleabilità è limitata dal potere espressivo del singolo \plugin{}. Infatti, quest'ultimo può offrire un contributo espresso sotto forma di una lista di coppie chiave-valore rappresentanti le informazioni che il \plugin{} andrà ad inserire all'interno dei templates\footnote{Ogni ``template'' rappresenta il contenuto testuale che andrà scritto sul file di configurazione indicato dal \plugin{} stesso; se più \plugin{} vogliono scrivere sul medesimo file di configurazione, il sistema non fa altro che accodare i vari templates.} che produrrà.

In questo capitolo discuteremo di come \visualnetkit{} sia stato profondamente modificato per dare la possibilità ai vari \plugin{} di poter ``abbracciare'' praticamente la totalità delle tipologie dei file di configurazione dei vari servizi (Dns, HTTP, E-Mail, Zebra, SSH, ecc\ldots). Si discuterà il problema dapprima analizzando alcune configurazioni avanzate di BGP e OSPF ed in secondo luogo si cercherà di estrapolare una struttura da poter descrivere all'interno dei vari \plugin{}. Successivamente si formalizzeranno i nuovi requisiti discutendo l'impatto di tali modifiche sul sistema attuale, ed in fine ci si addentrerà in uno studio di ``Analisi Architetturale'' del nuovo sistema di gestione delle properties dei \plugin{}.

\section{Scenari che Richiedono Configurazioni Avanzate}
Quando ci si misura con servizi complessi come Zebra\footnote{GNU Zebra è un software open-source che gestisce i protocolli di routing basati su TCP/IP. Supporta il protocollo BGP-4, come descritto nell'RFC-1771, come anche RIPv1, RIPv2 e OSPFv2.}, quasi sempre si ha a che fare anche con file di configurazione dall'alto potere espressivo e quindi potenzialmente complessi.

Andremo ora ad analizzare da vicino due esempi di configurazioni complesse in Zebra, in particolare nei protocolli BGP\footnote{Il \emph{Border Gateway Protocol} (BGP) è un protocollo di rete usato per connettere tra loro più router che appartengono a sistemi autonomi distinti e che vengono chiamati gateway.} e OSPF\footnote{Il protocollo \emph{Open Shortest Path First} (OSPF) è uno dei protocolli di instradamento più diffusi, che gestisce le tabelle di instradamento di una rete IP con il metodo del Link State.}, e cercheremo di trovare una possibile struttura comune che possa racchiuderli.

\subsection{Configurazione avanzata in BGP}
In questa sezione si cercherà di individuare una struttura comune in uno scenario reale, prendendo come esempio la configurazione BGP proposta in figura \ref{figura:bgp_conf_schema}.

\begin{figure}[!htb]
	\centering
	\includegraphics[width=10cm]{images/bgp_conf_schema.png}
	\caption{Una configurazione complessa di BGP.}
	\label{figura:bgp_conf_schema}
\end{figure}

Osservando la struttura del file di configurazione proposto, notiamo subito che vi è una struttura comune che può essere estrapolata e classificata. Senza considerare le righe $1\mapsto8$, che sono riconducibili ad una semplice lista di coppie chiave-valore, è opportuno soffermarci alle righe $9\mapsto13$; qui si trovano le network annunciate dal router in questione e può già essere dedotto che tale struttura è una lista con cardinalità 0..n di coppie con chiave ``network'' e con valore uguale all'indirizzo IP - seguito dalla netmask - che si vuole annunciare. Già in questo scenario una coppia chiave-valore (usata nella versione $1.0$ di \visualnetkit{}) non può essere utilizzata poiché solitamente le chiavi devono rimanere univoche.

Si osservino ora le righe $15\mapsto35$ analizzando in particolare le righe $19\mapsto23$. Come descritto nella documentazione di Zebra\cite{ZEBRADOC}, un ``peer'' ha la seguente sintassi:
\\
\\
\textbf{neighbor} \textit{peer} \textbf{remote-as} \textit{AS-Number}
\\
\textbf{neighbor} \textit{peer} \textbf{COMMAND}
\\
\\
dove \textbf{COMMAND} è uno dei comandi previsti da Zebra, come ad esempio \emph{description, default-originate, interface, version,} ecc\ldots, nonché comandi atti al \emph{Peer Filtering} quali \emph{distribuite-list, prefix-list, route-map,} ecc\ldots

\begin{figure}[!htb]
	\centering
	\includegraphics[width=6cm]{images/bgp_conf_tree.png}
	\caption{Configurazione complessa di BGP con struttura gerarchica.}
	\label{figura:bgp_conf_tree}
\end{figure}

Pertanto, anche in questo caso è possibile raggruppare le varie definizioni dei ``vicini'' (neighbor) in una struttura gerarchica in cui ogni neighbor ha una struttura composta da sotto-proprietà, eventualmente con proprietà che si riferiscono a nodi esterni, come nel caso \emph{prefix-list} (riga $22-23$). Proprio partendo da queste due righe di codice, è quindi possibile identificare proprietà correlate ad entità esterne (concetto simile alle chiavi esterne in uno schema relazionale di basi di dati); in definitiva si sta affermando che quella in questione non è nient'altro che una struttura ad albero n-ario che possiede un enorme potere descrittivo, ma allo stesso tempo una struttura complessa da gestire e manipolare. In figura \ref{figura:bgp_conf_tree} viene mostrata la mappatura del file di configurazione in esame (figura \ref{figura:bgp_conf_schema}) in un albero n-ario.

Questa non è che una delle tante possibili interpretazioni di un file di configurazione in una struttura gerarchica. Solitamente ogni file di configurazione (soprattutto nei sistemi \emph{Unix like}) possiede una struttura che è riconducibile ad una con caratteristiche gerarchiche. L'evoluzione che \visualnetkit{} ha avuto si è mossa proprio in questa direzione, in particolare trasformando il vecchio modello chiave-valore delle proprietà dei \plugin{}, in uno altamente dinamico (con la possibilità di inserire e/o eliminare proprietà) con struttura annidata.

\subsection{Configurazione avanzata in OSPF}
Si tenterà di applicare quanto detto poc'anzi ad un altro scenario reale che coinvolge il protocollo OSPF ed il suo file di configurazione. Prendiamo dunque in esame il file di configurazione mostrato in figura \ref{figura:ospf_conf}.

\begin{figure}[!htb]
	\centering
	\includegraphics[width=12cm]{images/ospf_conf_schema_tree.png}
	\caption{Configurazione di OSPF e relativa vista gerarchica.}
	\label{figura:ospf_conf}
\end{figure}

Anche in questo caso si può procedere nel tentativo di trasformare il contenuto del file di configurazione proposto, in una struttura descritta da un albero n-ario. È opportuno quindi iniziare ad analizzare il testo soffermandosi sulle righe $6\mapsto10$; si nota subito come questa porzione abbia una struttura abbastanza uniforme - come descritto nella documentazione\cite{ZEBRADOC} -, che può essere mappata all'interno di una struttura più auto-descrittiva e gerarchica (figura \ref{figura:ospf_conf}).

Analizzando poi le righe $15-16$ (tralasciando le altre) è possibile ricavare una struttura ben precisa, che nella documentazione di Zebra viene presentata nel seguente modo:
\\
\\
\textbf{network} \textit{a.b.c.d/m} \textbf{area} \textit{a.b.c.d}
\\
\textbf{network} \textit{a.b.c.d/m} \textbf{area} <\textit{0-4294967295}>
\\
\\
Naturalmente questi scenari sono soltanto alcuni dei tanti possibili contenuti che si possono trovare all'interno delle varie configurazioni, tuttavia è stato appena dimostrato che qualunque siano le regole presenti nelle varie impostazioni dei servizi utilizzati, si riesce sempre a ricondurre questi ultimi ad una rappresentazione gerarchica, talvolta anche complessa.

\section{Requisiti per un Ambiente di Configurazione Avanzata}
Prima di trasformare il sistema in modo da essere riadattato a quanto detto fin'ora, è preferibile formalizzare i nuovi requisiti - sia quelli funzionali, che non - per avere un quadro complessivo e non ambiguo su quello che il nuovo sistema dovrà offrire. 

Si è cercato di individuare gli attori principali discutendo con gli \stakeholders{} per avere più punti vi vista. Gli attori individuati sono due:
\begin{itemize}
\item l'utente che utilizza \visualnetkit{}, in particolare uno dei suoi \plugin{};
\item l'utente/sviluppatore che desidera realizzare un \plugin{} dalle caratteristiche avanzate.
\end{itemize}
Sono stati quindi definiti una serie di scenari principali di successo per ciascun caso d'uso semplificato. L'insieme degli scenari ritenuto più importante verrà presentato in seguito. Con il termine ``end user'' si denota l'utente che utilizza \visualnetkit{}, e con il termine ``plugin developer'' colui che vuole realizzare un \plugin{}.

\begin{flushleft}
\begin{boxedminipage}{\textwidth}

\subsubsection*{Caso d'uso - Inizializzazione dei \plugin{} selezionati}

\textbf{Scopo:} applicazione \visualnetkit{} \\
\textbf{Livello:} user goal \\
\textbf{Attore Primario:} End user \\
\textbf{Parti interessate e interessi:}
\begin{itemize}
\item End user: desidera un interazione semplice, veloce ed intuitiva con il sistema per raggiungere i propri obiettivi con il minimo sforzo.
\end{itemize}

\textbf{Prerequisiti:} il sistema deve essere avviato e l'utente deve aver creato un nuovo Lab. \\
\textbf{Goal:} l'utente ha creato un elemento base (una virtual machine, un collision domain o un link) e aver scelto ed inizializzato i \plugin{} che ha selezionato. Il sistema mostra sulla scena grafica l'elemento creato. \\

\textbf{Scenario di successo:}
\begin{enumerate}
\item l'utente seleziona dalla tool-bar o dal menu la tipologia dell'elemento che intende aggiungere;
\item l'utente clicca con il mouse - tasto sinistro - un punto della scena grafica e il sistema provvede a mostrare la form per l'inizializzazione dei parametri;
\item l'utente completa la form attivando inoltre i \plugin{} che desidera attivare;
\item qualora l'utente voglia modificare i valori di default dei \plugin{} selezionati, il sistema mostra una successiva form che offre la possibilità di mutare i vari campi delle property, nonché la possibilità di modificare la struttura delle stesse tramite l'apposito bottone ``actions'';
\item l'utente accetta e il sistema provvede a chiudere la form;
\item il sistema inizializza ed aggiorna il suo stato aggiungendo, l'elemento selezionato e mostrandolo all'utente.
\end{enumerate}

\end{boxedminipage}
\end{flushleft}

\begin{flushleft}
\begin{boxedminipage}{\textwidth}

\subsubsection*{Caso d'uso - Modifica delle proprietà di un elemento}

\textbf{Scopo:} applicazione \visualnetkit{} \\
\textbf{Livello:} user goal \\
\textbf{Attore Primario:} End user \\
\textbf{Parti interessate e interessi:}
\begin{itemize}
\item End user: desidera un'interazione semplice, veloce ed intuitiva con il sistema, per raggiungere i propri obiettivi con il minimo sforzo.
\end{itemize}

\textbf{Prerequisiti:} il sistema necessita di essere avviato, l'utente deve aver creato un nuovo Lab e deve essere presente almeno un elemento base. \\
\textbf{Goal:} l'utente è riuscito con successo a modificare - nel contenuto o nella struttura - una delle proprietà di un elemento selezionato. Il sistema ha provveduto all'acquisizione dei cambiamenti, modificando le proprie strutture interne.

\textbf{Scenario di successo:}
\begin{enumerate}
\item l'utente clicca due volte con il mouse un elemento presente nella scena grafica, oppure clicca un elemento mostrato nell'insieme degli oggetti presenti, selezionandolo;
\item il sistema mostra nella ``property dock'' le proprietà dell'elemento selezionato catalogate e suddivise in base al loro ruolo: proprietà costitutive dell'elemento base e proprietà offerte dai \plugin{} attivi;
\item l'utente modifica il contenuto di una proprietà. Il sistema provvede a validare il valore inserito e a registrare i cambiamenti effettuati, eventualmente aggiornando gli elementi grafici;
\item l'utente intende modificare la struttura delle proprietà di uno dei \plugin{} presenti:
	\begin{enumerate}
	\item l'utente desidera aggiungere una proprietà o sotto-proprietà dopo averne selezionata un'altra. Tramite l'apposito bottone ``actions'' questi può inserire altre sotto-proprietà che automaticamente il sistema propone come possibili candidate. Dopo aver inserito una nuova proprietà, il sistema registra il cambiamento al suo interno;
	\item l'utente desidera eliminare una proprietà dopo averla selezionata. Tramite il bottone ``actions'' questi seleziona ``elimina proprietà'' e il sistema (validando o meno l'operazione) provvede a modificare le proprie strutture interne.
	\end{enumerate}
\end{enumerate}

\end{boxedminipage}
\end{flushleft}
Abbiamo analizzato i due principali scenari di successo che l'utente finale si dovrebbe aspettare, ora ci preoccuperemo di analizzare altri scenari di successo che riguardano le aspettative dell'utente (plugin developer). In particolare gli scenari indicano come lo sviluppatore può usufruire della possibilità di impostare configurazioni avanzate per il servizio che egli stesso intende descrive.

\begin{flushleft}
\begin{boxedminipage}{\textwidth}

\subsubsection*{Caso d'uso - Creazione di \plugin{} avanzati}

\textbf{Scopo:} \plugin{} per \visualnetkit{} \\
\textbf{Livello:} sub-function \\
\textbf{Attore Primario:} plugin developer \\
\textbf{Parti interessate e interessi:}
\begin{itemize}
\item Plugin developer: si aspetta di riuscire a creare il proprio \plugin{}, che dovrà contenere una struttura flessibile tale da poter descrivere la maggior parte delle configurazioni avanzate di un certo servizio offerto dal \plugin{} stesso.
\end{itemize}

\textbf{Goal:} lo sviluppatore realizza un \plugin{} per un determinato servizio che al suo interno possiede flessibilità e alta adattabilità, in modo da offrire anche configurazioni complesse.

\textbf{Scenario di successo:}
\begin{enumerate}
\item lo sviluppatore costruisce il file di configurazione per il suo \plugin{} descrivendo in modo dettagliato la struttura delle proprietà;
\item lo sviluppatore crea il proprio \plugin{} che offrirà agli utenti finali la possibilità di una particolare estensione dell'elemento base su cui si fonda il \plugin{};
\item il sistema provvede a caricare il \plugin{} durante l'avvio e ad offrire all'utente finale la possibilità di selezionarlo.
\end{enumerate}

\end{boxedminipage}
\end{flushleft}

In figura \ref{figura:uc1} viene proposto il diagramma completo dei casi d'uso e l'interazione tra di essi.

\begin{figure}[!htb]
	\centering
	\includegraphics[width=12cm]{images/UseCaseModel.png}
	\caption{Diagramma dei casi d'uso principali in \visualnetkit{}.}
	\label{figura:uc1}
\end{figure}

\subsubsection{L'impatto sul sistema}
Verrà ora analizzato in dettaglio quale sarà l'impatto sul sistema che prevede properties unicamente descritte da una lista di coppie chiave-valore. Si sta di fatto introducendo un cambiamento piuttosto radicale che andrà a coinvolgere da una parte il core di \visualnetkit{} e dall'altra il framework che supporta l'architettura modulare. Scendendo nei particolari ci si dovrà muovere con una strategia \bu{} effettuando un restyling del \plugin{} framework, introducendo nuove funzionalità al sistema. Queste ultime interagiranno con i moduli per interrogare le loro proprietà\footnote{Si ricorda che le proprietà saranno contenute in strutture ad alberi n-ari, non facilmente gestibili.} e per validare ed interpellare il loro file di configurazione \xml{}.

Successivamente si andrà a rimodellare la GUI che sarà dotata di una nuova property dock. Anche il core stesso dell'applicazione dovrà essere rivisitato; i vari handler che raccolgono le modifiche effettuate dall'utente all'interno delle proprietà, andranno migliorati e correlati tra loro. In tutto questo giocherà un ruolo fondamentale il potente framework \qt{}, basato pesantemente sul pattern architetturale \emph{MVC}\cite{QTDOCMVC}.

\section{Analisi Architetturale}
In questa sezione si raccoglieranno tutti i requisiti descritti precedentemente e, rispettando la tassonomia dell'attuale sistema, si cercherà di formalizzare le modifiche che verranno poi applicate su \visualnetkit{}. Una prima fase di analisi è stata spesa per carpire adeguatamente il tipo di supporto offerto da \qt{}, in particolare i concetti su cui si basa il sistema \emph{Model/View}.

\subsubsection*{L'architettura Model/View in \qt{}}
Model-View-Controller (MVC) è un pattern apparso per la prima volta nel $1971$ all'interno del linguaggio di programmazione \emph{Smaltalk}, spesso applicato a scenari in cui l'interfaccia utente gioca un ruolo chiave. \qt{} separa le varie classi all'interno di tre gruppi: models, views e delegates. Ognuno di questi componenti è definito da una classe astratta comune che offre implementazioni di default di uso generico.

\begin{figure}[!htb]
	\centering
	\includegraphics[width=6cm]{images/modelview-overview.png}
	\caption{MVC all'interno di \qt{}$4$.}
	\label{figura:qt_mvc}
\end{figure}

Tutti i modelli sono basati sulla classe \emph{QAbstractItemModel}. Questa definisce un'interfaccia che viene usata dalla vista (View) attraverso il delegato, per accedere ai dati. I dati stessi non sono presenti nel modello, ma vengono immagazzinati in strutture separate che possono essere classi, files, database o altri tipi di contenitori.
Le viste invece implementano la parte visiva dei dati presentata all'utente finale. \qt{} offre tre tipologie di viste utilizzate, a seconda dei casi: Tabelle, Liste o Alberi. In particolare, ogni vista renderizza (tramite il delegato) le informazioni presenti nelle strutture dati gestite dal modello, e questo offre la possibilità ad ogni modello di essere visualizzato all'interno di viste differenti\footnote{Si pensi a dati anagrafici che devono essere mostrati in più tipologie di grafici: grafici a torta, a barre, istogrammi, ecc\ldots}.

I delegati sono elementi di estrema importanza all'interno del framework. Questi fungono da livello di indirezione tra la vista e il modello ed offrono supporto alla renderizzazione dei dati. È infatti possibile re-implementare la classe astratta che descrive tutti i delegati (\emph{QAbstractItemDelegate}) per poter ad esempio inserire diversi widget di input nei campi mostrati in una tabella, come mostrato in figura \ref{figura:qt_delegate}.

\begin{figure}[!htb]
	\centering
	\includegraphics[width=6cm]{images/spinboxdelegate-example.png}
	\caption{Un esempio di ``delegate'' in \qt{}$4$.}
	\label{figura:qt_delegate}
\end{figure}

\subsubsection*{Utilizzo di MVC nel nuovo property system}
Quanto appena descritto ha giocato un ruolo fondamentale nella comprensione del metodo più adatto ad effettuare le modifiche alle proprietà, sfruttando al meglio gli strumenti offerti da \qt{}. Come primo test si è partiti con un prototipo di property editor sul quale effettuare i vari esperimenti, cercando di mantenere il codice pulito per il riuso.
Questa fase si affronta solitamente per fronteggiare problemi e risolverli al meglio. Il modello di MVC che \qt{} propone è stato sfruttato in tutti i suoi dettagli tranne che per i delegati in quanto, per gli scopi prefissati, non erano previste tipizzazioni nei campi valori delle proprietà.

Si è dunque partiti col creare una struttura ad albero n-ario, passando poi alla costruzione del modello, per finire quindi con la vista e l'interazione tra quest'ultima ed il modello stesso, ponendo particolare attenzione all'accoppiamento e alla coesione degli oggetti.

Durante la modellazione è stato deciso di accentrare il controllo su di un'entità astratta che fosse stata in stretto contatto con i dati e che raccogliesse le richieste di cambiamento. Uno dei primi problemi riscontrati riguarda il fatto che il property editor sarebbe stato utilizzato non solo dagli elementi base di \visualnetkit{}, ma anche ad altri componenti quali Aree grafiche e proprietà stesse del laboratorio, prive di un interfaccia verso i \plugin{}. Di qui la necessità di generalizzare il concetto di ``property handler'' tale da poter risultare abbastanza generale da essere esteso dai vari controllers concreti.

\subsection{\plugin{} per la Configurazione Avanzata}
In questa sezione ci occuperemo di analizzare quanto sopra descritto. Si osservi quindi la figura \ref{figura:properties_uml1}.

\begin{figure}[!htb]
	\centering
	\includegraphics[width=12cm]{images/properties_uml1.png}
	\caption{Diagramma delle classi del nuovo sistema.}
	\label{figura:properties_uml1}
\end{figure}

Si nota subito la presenza di una generalizzazione per quanto riguarda il property handler, come precedentemente accennato. Tale interfaccia (in \cpp{} è chiamata una ``pure abstract class'') offre le seguenti funzioni:
\begin{description}
\item[getComposedModel()]questa funzione indica che ogni classe che la estende deve necessariamente fornire un model appropriamente costruito, il quale verrà poi collegato alla vista. Il model viene creato ricavando le informazioni dall'elemento base e dalle properties offerte dai vari \plugin{} che aggrega. Ogni ``tree item'' possiede quindi il riferimento al suo creatore, che è anche l'oggetto che riceve le richieste di cambiamento;

\item[getInitMolel()]questa funzione viene usata dalle sotto-classi che adempiono il ruolo di property controllers per gli elementi base\footnote{Ricordiamo che per ``elemento base'' in \visualnetkit{} si intendono Virtual Machines, Collision Domains e Links.}, fornendo un modello simile al precedente ma che contiene solamente i dati dei \plugin{} selezionati;

\item[saveChangedProperty()]viene utilizzata per il salvataggio dei cambiamenti effettuati in una determinata proprerty;

\item[getPluginFromCurrentElement()]questa funzione è puramente di convenienza e viene usata di rado;

\item[removePluginProperty()]viene utilizzata per inoltrare la richiesta di eliminazione di una property di un \plugin{}. Il controllo di consistenza viene effettuato dal modulo stesso;

\item[addPluginProperty()]come sopra, ma utilizzata per inserire una property (o sub-property) in un \plugin{}.
\end{description}

Si arriva quindi ad avere un forte incremento di flessibilità ed estensibilità grazie all'aggiunta di properties dei moduli non più statiche bensì dinamiche, con struttura anche annidata (figura \ref{figura:property_editor_paragone}).

\begin{figure}[!htb]
	\centering
	\includegraphics[width=12cm]{images/property_editors_paragone.png}
	\caption{Paragone tra il vecchio ed il nuovo property editor.}
	\label{figura:property_editor_paragone}
\end{figure}


\subsection{Metodologie di sviluppo adottate}
Al fine di rendere la progettazione più corretta e la fase di implementazione meno rischiosa, si è cercato di cogliere gli aspetti qualificanti di metodologie di sviluppo quali \textit{XP}, \textit{FDD} e le più note metodologie di sviluppo iterativo come \textit{UP} (\emph{Unified Process}).
Seguendo le linee guida dettate da \textit{UP}, si è optato per la definizione di cicli di sviluppo scanditi dal rilascio di prototipi funzionanti del progetto e dalla loro presentazione e discussione, così da avere una valutazione dell'avanzamento dello stesso ed una buona gestione dei fattori di rischio. Ogni ciclo è stato suddiviso in tre fasi: \textit{inception phase}, \textit{elaboration phase} e \textit{construction phase}.
Scopo principale della fase iniziale è stato quello di delineare, nel modo più accurato possibile, il caso di interesse e di identificare gli elementi importanti affinché esso conduca al completamento delle funzionalità desiderate.

Nel primo ciclo di analisi e progettazione, questo stadio è stato supportato da strumenti quali un modello dei casi d'uso sufficientemente dettagliato da definire i principali obiettivi del progetto, una pianificazione dello stesso e delle prime fasi evolutive, una valutazione dei rischi ed una definizione primaria dei requisiti.
Lo step che coinvolge l'elaborazione ha contribuito a definire la struttura complessiva del sistema. Questo ha compreso l'analisi di dominio ed un primo approccio alla progettazione dell'architettura a cui si è affiancato lo studio per la rappresentazione del modello logico.

Al termine di queste due è seguita una fase conclusiva di implementazione e rilascio di un prototipo e sotto-versioni dell'architettura, capaci di mostrare il completamento dei casi d'uso principali e delle funzionalità introdotte nei punti precedenti.

A dispetto delle linee guida proposte dalla metodologia \emph{UP}, le quali prevedono una quarta \textit{fase di transizione} in cui vengono condotte le attività di training e il \textit{beta testing}\footnote{Il beta testing (o beta-verifica) è un periodo di prova e collaudo di un software non ancora pubblicato, con lo scopo di trovare eventuali errori (bug). Questa operazione può essere svolta da professionisti pagati oppure, molto spesso, da semplici amatori (chiamati beta-testers).} del sistema a scopo di verifica e validazione, ogni fase è stata arricchita da piccole iterazioni di analisi e test limitando considerevolmente l'overhead complessivo.

La metodologia \textit{XP} è stata abbracciata negli steps di verifica continua del progetto; la frequente reingegnerizzazione del software e la libertà di seguire o meno le fasi di sviluppo prefissate, ci ha permesso di raggiungere rapidi risultati. Nei punti finali dello sviluppo, per il raffinamento e perfezionamento delle funzionalità accessorie, si è optato per un tipo di sviluppo orientato verso \textit{FDD} (\textit{Feature Driven Development}).
Quest'ultima, anch'essa parte dell'\textit{Agile Manifesto}, cerca di spingere \textit{XP} verso un'estrema flessibilità eliminando interamente la fase classica di progettazione e volgendo il pieno interesse verso le fasi di ``definizione di una lista di funzionalità'' e di uno ``sviluppo per funzionalità''.
